Как вы знаете, на прошедшей конференции Explore 2022 компания VMware анонсировала новые версии платформы виртуализации vSphere 8 и решения для создания отказоустойчивых хранилищ vSAN 8. Недавно эти решения стали доступны для скачивания как Initial Availability (IA), поэтому сейчас самое время развертывать их в своих тестовых окружениях для проверки перед большим апгрейдом.

Начать можно с виртуальной тестовой лаборатории, то есть инсталляции в рамках одного сервера или рабочей станции, где сервисы ESXi, vCenter и vSAN поднимаются в виртуальных машинах.

Для этой цели известный блоггер и инженер VMware Вильям Ламм создал на PowerCLI специальный сценарий Automated vSphere & vSAN 8 Lab Deployment, который автоматизирует развертывание компонентов виртуальной лаборатории на базе vSphere и vSAN восьмой версии.

Как видно на картинке, скрипт предназначен, чтобы развернуть три виртуальных сервера ESXi, создать на их базе кластер vSAN, а также развернуть виртуальный модуль управления vCenter Server Appliance (vCSA).

Итак для этого вам понадобятся:

• Действующий vCenter Server не ниже седьмой версии
• Компьютер Windows, Mac или Linux с установленным PowerShell Core и фреймворком PowerCLI 12.1 Core
• Виртуальный модуль vCenter Server Appliance 8.0 Build 20519528 OVA
• Виртуальный модуль Nested ESXi 8.0 IA OVA

Перед исполнением сценария вам нужно заполнить все его параметры, относящиеся к вашей текущей инфраструктуре и к создаваемой тестовой лаборатории, а также распаковать содержимое ISO-образа виртуального сервера vCSA.

Пример исполнения сценария показан ниже:

В итоге процесс будет выполняться пошагово до его завершения с информацией о каждом шаге:

Ну и после всего этого в vSphere Client вы увидите вашу созданную виртуальную тестовую лабораторию с тремя хостами ESXi и сервером управления vCenter / vCSA:

Скачать сценарий Automated vSphere & vSAN 8 Lab Deployment можно по этой ссылке, там же есть более подробная информация о том, как его использовать.

На сайте проекта VMware Labs появилась еще одна интересная утилита Horizon Network Label Assignment Tool. Она предназначена для решения проблемы исчерпания IP-адресов в сетях, назначаемых виртуальным машинам пулов VMware Horizon.

Виртуальные десктопы в пулах Horizon Automated Linked Clone или Full Clone по умолчанию наследуют сетевой интерфейс (NIC) с сетью (network label) от родительской виртуальной машины или шаблона. Это означает, что если в этой сети кончаются IP-адреса, то там уже нельзя развернуть новые машины и администратору нужно как-то расширить диапазон адресов в сети для пула или добавить новую сеть, назначив ее членам пула.

Horizon Network Label Assignment Tool помогает администратору развертывать большие пулы десктопов с одной родительской виртуальной машиной (Parent Virtual Machine) или шаблоном (Template) за счет установки сети из нескольких доступных, которые настроены на хосте ESXi нужного кластера. Утилита также дает возможность сбросить и просмотреть установленные ранее настройки network label в табличном формате.

Network Label Assignment Tool дает возможность изменять сети для следующих пулов и ферм виртуальных ПК:

• Пулы Linked Clones Automated Desktop
• Пулы Full Clone Automated Desktop
• Фермы RDS (Linked Clones)   

Вот какие настройки доступны в интерфейсе утилиты:

• Задание настроек Network Label для пулов и ферм
• Сброс этих настроек до изначальной сети родительской ВМ или шаблона
• Просмотр существующих настроек для пулов и ферм

Утилита Horizon Network Label Assignment Tool построена на базе Windows PowerShell и имеет следующие требования:

• Windows 10 x64 / Windows Server 2016 или более поздние
• PowerShell версии 5.1
• Модуль VMware PowerCLI
• Horizon 7.13.x / Horizon 8 2006 (поддержка пулов и ферм) Horizon 8 2012 (поддержка только пулов) или более поздние

Скачать Horizon Network Label Assignment Tool можно по этой ссылке, документация доступна тут.

Компания Altaro, разрабатывающая продукты для резервного копирования и восстановления данных виртуальной инфраструктуры, недавно опубликовала свой топ из 24 Open Source утилит компании VMware, который мы приводим ниже. Благодарим нашего читателя Ser за ссылку.

Итак, собственно сам топ из 24 Open Source проектов VMware:

1. Tanzu Community Edition - бесплатный open source дистрибутив VMware Tanzu, который поддерживается со стороны открытого сообщества, а устанавливается за считанные минуты на локальную рабочую станцию или в облаке. Мы писали об этом продукте тут.
2. Carvel - это набор из различных утилит для создания приложений, их конфигурации и развертывания в среде Kubernetes.
3. Octant - решение для визуализации кластера Kubernetes на дэшборде с точки зрения пространств имен и объектов, которые они содержат. Также там отображаются связи объектов и ресурсов. В отличие от дэшборда Kubernetes, Octant запускается локально на вашей рабочей станции, что позволяет избежать проблем, связанных с требованиями к безопасности. Мы писали об этой утилите тут.
4. Photon - операционная система от VMware, которая используется в виртуальных модулях (Virtual Appliances), реализующих различные вспомогательные сервисы виртуальной инфраструктуры. О последней версии этой ОС мы писали вот тут.
5. NSX Container Plug-in - это плагин, который реализует интеграцию между NSX-T и Kubernetes, а также с такими PaaS-платформами, как OpenShift и Tanzu Application Service (TAS).
6. Harbor - этот компонент позволяет хранить образы контейнеров. Если вам необходимо поместить приложение в контейнер и распространять его в своей инфраструктуре, нужно воспользоваться таким реестром. Для движка Docker - это компонент Docker Hub. Проблема в том, что репозиторий Docker Hub открыт абсолютно всем, поэтому VMware сделала свой репозиторий Project Harbor (это форк проекта Docker Hub), который также является Open Source-компонентом, но предоставляет отдельное корпоративное хранилище образов в рамках инфраструктуры компании. Поставляется он в виде виртуального модуля в формате OVA. Об этом продукте мы упоминали тут.
7. Antrea - это решение позволяет пользователям кластеров Kubernetes на платформе VMware управлять сетевым взаимодействием контейнеров на базе политик. На базе этой платформы построен также и коммерческий продукт VMware Container Networking with Antrea - решение для публичных и частных облаков, использующих Open vSwitch, которое позволяет управлять сетевым взаимодействием на нескольких уровнях с предоставлением поддержки со стороны VMware. О проекте Antrea мы писали вот тут.
8. Herald - это набор API, который позволяет разработчикам создавать приложения на базе протоколов коммуникации между различными устройствами. Например, это полезно в медицине, где нужны приложения для трекинга состояния устройств и своевременного оповещения различных служб.
9. Pinniped - это проект, реализующий сервисы идентификации (identity services) для инфраструктуры Kubernetes.
10. Avi Kubernetes Operator (AKO) - это Kubernetes-оператор, который взаимодействует с Kubernetes API и компонентом балансировщика AVI controller (теперь он называется NSX Advanced Load Balancer). 
11. Salt Project - комплекс решений, купленных VMware вместе с компанией Salt, предназначенный для управления конфигурациями ОС и приложений, а также автоматизации и оркестрации процессов на базе событий.
12. Container Service Extension - это продукт, который дает функции по управлению жизненным циклом всех типов кластеров Kubernetes через Cloud Director Cluster API, CLI и Container Service Extension-CLI, а также плагин в графическом интерфейсе.
13. PowerCLI example scripts - это репозиторий на GitHub, содержащий большое количество сценариев, полезных администраторам в ежедневном применении. Например, к ним относится утилита для отчетности о состоянии виртуальной инфраструктуры vCheck, о которой мы писали вот тут.
14. Flowgate - это решение представляет собой средство агрегации данных из различных источников. Это middleware, которое позволяет провести агрегацию данных систем инвентаризации датацентров DCIM / CMDB и далее передать их в системы управления задачами инфраструктуры (например, vRealize Operations). О Flowgate мы писали вот тут.
15. vSphere Integrated Containers - это решение позволяет создавать инфраструктуру виртуальных контейнеров в виртуальных машинах vSphere. Последний раз мы писали об этом продукте тут.
16. Weathervane - это бенчмаркинг-утилита, предназначенная для запуска тестов производительности в виртуальных средах VMware vSphere (как онпремизных, так и облачных), с учетом симуляции реальной нагрузки различных приложений. О второй ее версии мы писали тут.
17. Pyvmomi - это Python SDK для VMware vSphere API, которая позволяет управлять хостами VMware ESXi и vCenter. Также мы писали о средстве VMFork for pyVmomi, предназначенном для администраторов, которые любят ставить всяческие эксперименты со скриптами. Эта утилитка позволяет создать работающую копию запущенной виртуальной машины посредством скрипта на Python, через VMware vSphere API Python Bindings.
18. Contour - это легковесный Ingress-контроллер для Kubernetes, который работает за счет развертывания Envoy-прокси в качестве reverse proxy и балансировщика нагрузки. 
19. Velero - это решение для создания и хранения резервных копий ресурсов кластера K8s (etcd), предназначенное для защиты данных на персистентных томах.
20. Sonobuoy - это утилита для диагностики и отчетности кластеров Kubernetes, которая позволяет оценить их состояние.
21. VMware Event Broker Appliance (VEBA) - это средство предназначено для создания сценариев автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That". В последний раз мы писали о VEBA вот тут.
22. Cluster API vSphere Provider - это Cluster API, позволяющий расширить возможности Kubernetes за счет определений CRD и операторов, которые позволяют вам управлять кластерами на базе определений по аналогии с тем, как управляются объекты pods, deployments и services.
23. Concourse - это проект VMware, который представляет собой open source утилиту CI/CD для Cloud Foundry.
24. Open VM Tools - это пакеты VMware Tools с открытым исходным кодом, которые встраиваются в большинство современных Linux-дистрибутивов. Соответственно, при установке такой гостевой ОС в виртуальной машине, пакет VMware Tools будет там уже установлен. Исходный код OVT доступен для всех желающих в репозитории на GitHub, но официально поддерживаются только те OVT, которые идут вместе с дистрибутивами Linux. Если вы скомпилировали их самостоятельно - учтите, поддержки от VMware не будет.

На этом топ заканчивается, но количество Open Source инструментов у VMware на данный момент насчитывает более 200 проектов. Их полный список можно посмотреть по этой ссылке.

На днях компания VMware объявила о выпуске обновленной версии своего фреймворка для управления виртуальной инфраструктурой с помощью скриптов - PowerCLI 12.7. Напомним, что о прошлой версии PowerCLI 12.6 мы рассказывали вот тут.

Итак, давайте посмотрим на новые возможности PowerCLI 12.7:

1. Мультиплатформенный модуль VUM

Теперь модуль, предназначенный для обновлений компонентов виртуальной инфраструктуры, работает на платформах Linux и macOS, что очень давно просили пользователи. До этого момента оставалось только 2 модуля, которые не были портированы на эти ОС, теперь же PowerCLI стал полностью мультиплатформенным фреймворком (кстати, 40% всех его пользователей работают на Linux и macOS).

2. Улучшения модуля NSX

В PowerCLI 12.6 появился новый модуль NSX SDK, в этом же релизе для него появились функции поддержки последнего NSX API, включая удаленную аутентификацию в командлете Connect-NsxServer с использованием параметра -UseRemoteAuthentication. Также был улучшен механизм использования командлета Get-NsxOperation.

3. Новые параметры конфигурации кластера vSAN

Теперь для кластера vSAN можно установить пороговые значения для механизма health check, используя параметр -CapacityThreshold для командлетов Set-VsanClusterConfiguration и New-VsanHealthCheckThreshold. Например, так:

$newThreshold = New-VsanHealthCheckThreshold -Enabled $true -YellowValue 95 -RedValue 99 -Target VsanDatastore
Set-VsanClusterConfiguration -Configuration $cluster -CapacityThreshold $newThreshold -HistoricalHealthEnabled $false

Также можно отключить/включить исторические данные vSAN health check, а также смонтировать/размонтировать датастор с другого кластера как удаленный датастор с помощью командлета Set-VsanClusterConfiguration.

$remoteDatastore = Get-Datastore 'MyDatastore'
Set-VsanClusterConfiguration -Configuration $cluster -MountRemoteDatastore $remoteDatastore

Кроме перечисленного, в PowerCLI 12.7 появилось много небольших улучшений, таких как, например, увеличение производительности при работе с решениями SRM и HCX. Более подробный список улучшений приведен в Release Notes. Документация по работе с командлетами VMware PowerCLI 12.7 находится тут.

В апреле компания VMware выпустила обновление своего основного фреймворка для управления виртуальной инфраструктурой и ее компонентами из командной строки PowerCLI 12.6. О прошлой версии PowerCLI 12.5 мы писали в январе вот тут, а сегодня расскажем, что появилось нового в весеннем обновлении.

Основные улучшения и нововведения:

1. Байндинги PowerShell для интерфейсов NSX Policy Manager API.

Теперь появился новый модуль VMware.Sdk.Nsx.Policy, который реализует байндинг PowerShell для программных интерфейсов NSX Policy Manager API.

2. Новые командлеты для управления виртуальным модулем vCenter Server Appliance.

Теперь для управления резервными копиями vCenter Server Appliance можно использовать следующие командлеты:

• New-ApplianceBackupJob - стартует задачу резервного копирования на уровне файлов vCenter Server на бэкап-сервер.
• Wait-ApplianceBackupJob - мониторит прогресс задачи резервного копирования и возвращает в ApplianceBackupJob.
• Get-ApplianceBackupJob - получает список завершенных или находящихся в исполнении задач резервного копирования.
• Stop-ApplianceBackupJob - останавливает задачи РК в соответствии с указанными параметрами.
• Get-ApplianceBackupPart - получает список частей (parts), которые могут быть включены в задачу РК, а также их размер в резервной копии. Обязательные части всегда включаются в бэкап.

3. Поддержка SRM 8.5.

Модуль VMware.VimAutomation.Srm был обновлен и теперь поддерживает решение VMware Site Recovery Manager 8.5.

4. Исправления ошибок.

VMware приводит таблицу с багофиксами:

Загрузить компоненты фреймворка VMware PowerCLI 12.6 можно по этой ссылке. Release notes доступны тут.

На сайте проекта VMware Labs обновилась версия виртуального модуля VMware Event Broker Appliance (VEBA) до версии v0.7.2. Напомним, что это средство позволяет пользователям создавать сценарии автоматизации на базе событий, генерируемых в VMware vCenter Service. Например, VEBA может выполнять такие рабочие процессы, как автоматическое привязывание нужного тэга ко вновь создаваемой виртуальной машине. Работает он по модели "If This Then That".

Вот что нового появилось в VEBA 0.7.2:

• Новый шаблон Knative PowerCLI, который позволяет быстро создавать новые функции
• Улучшения функции PowerShell Slack, которая теперь не зависит от типов событий и имеет кастомизируемые сообщения
• Новые примеры функций PowerCLI (тут и тут), чтобы применять конфигурации распределенного коммутатора VDS и групп портов DVPortgroup
• Теперь Syslog получает все логи через Fluentbit
• Механизм триггеров RabbitMQ теперь поддерживает масштабирование функций в случае, когда идет большой поток событий
• Добавлена документация по бесплатному Let's Encrypt
• Различные исправления ошибок, полный список которых приведен тут

Скачать виртуальный модуль VMware Event Broker Appliance (VEBA) v0.7.2 можно по этой ссылке.

Почти два года назад мы писали об особенностях управления сертификатами в обновленной инфраструктуре vSphere 7. Сегодня мы расскажем об управлении сертификатами VMware vSphere с помощью PowerCLI на основе материалов вот этой статьи в блоге VMware.

Все необходимые функции для работы с API по управлению сертификатами были добавлены в PowerCLI версии 12.4 в конце прошлого года, и теперь можно полноценно управлять ими с помощью сценариев.

Вот какие командлеты используются в VMware vSphere 7 (некоторые из них доступны и в более ранних версиях платформы) для получения информации о сертификатах, их добавления и удаления:

• Add-VITrustedCertificate
• Get-VIMachineCertificate
• Get-VITrustedCertificate
• New-VIMachineCertificateSigningRequest
• Remove-VITrustedCertificate
• Set-VIMachineCertificate

Итак, давайте посмотрим, как они работают:

1. Управление доверенным хранилищем сертификатов

Для работы с Trusted Certificate Store можно использовать командлет Get-VITrustedCertificate, который проверяет корневые сертификаты на сервере vCenter Server и/или на присоединенных хостах ESXi (параметры issuer, expiration date, serial number и другие). Вот пример, как проверить хранилища сертификатов на серверах на предмет устаревших сертификатов:

#Check the trusted certificate store of the vCenter and all connected ESXi servers for expired certificates

Get-VITrustedCertificate | Where-Object { $_.NotValidAfter -lt (Get-Date) }

Если мы хотим добавить сертификат или цепочку сертификатов в центр сертификации (certificate authority), который мы используем для хранилища сертификатов, можно использовать командлет Add-VITrustedCertificate:

#Read the certificate or certificate chain from a .pem file

$trustedCertChain = Get-Content "C:\Users\jdoe\Downloads\ca-chain.cert.pem" -Raw



#Add it to the trusted certificate stores of the vCenter and the ESXi servers

Add-VITrustedCertificate -PemCertificateOrChain $trustedCertChain

Также есть командлет Remove-VITrustedCertificate для удаления доверенных сертификатов, которые нам больше не нужны (используйте ее очень осторожно, ведь можно случайно удалить используемый сертификат). В интерфейсе этой функции нет, чтобы администратор случайно не удалил нужные сертификаты из цепочек. Вот как это работает:

Get-VITrustedCertificate -VCenterOnly | `

Where-Object { $_.NotValidAfter -lt (Get-Date) } | `

Remove-VITrustedCertificate

2. Управление SSL-сертификатами компьютеров на сервере vCenter Server

Если у нас есть несколько компьютеров, с которых администраторы получают доступ к vSphere Client, и мы хотим, чтобы сертификаты принимались по умолчанию, мы должны заменить сертификаты на сгенерированные доверенным центром сертификации (trusted certificate authority).

Сначала с помощью этого командлета проверяем текущий сертификат машины vCenter:

Get-VIMachineCertificate -VCenterOnly

После этого создаем запрос на подписку сертификата (certificate signing request, CSR) для vCenter Server. Можно использовать командлет VIMachineCertificateSigningRequest:

$csrParams = @{

Country="US"

Email="jdoe@vmware.com"

Locality="San Francisco"

Organization="My Company"

OrganizationUnit="PowerCLI"

StateOrProvince="California"

}

$csr = New-VIMachineCertificateSigningRequest @csrParams


$csr.CertificateRequestPEM | Out-File "C:\Users\jdoe\Downloads\vc.csr.pem" -Force

После того, как мы получим файл сертификата от центра сертификации, мы можем заменить сертификат машины vCenter с помощью командлета Set-VIMachineCertificate:

$vcCert = Get-Content "C:\Users\jdoe\Downloads\vc.cert.jdoe.pem" -Raw

Set-VIMachineCertificate -PemCertificate $vcCert

Перед установкой SSL-сертификата машины мы должны убедиться, что корневой сертификат нашего CA добавлен в хранилище сертификатов vCenter Server. Помните, что замена сертификата вызовет перезагрузку vCenter.

3. Управление SSL-сертификатами машин для серверов ESXi

Если мы хотим управлять сертификатами полностью самостоятельно, нужно также заменить и сертификаты хостов ESXi. Рабочий процесс в этом случае выглядит несколько сложнее. Сначала нужно изменить настройку режима управления сертификатами хостов ESXi на custom на сервере vCenter и перезагрузить его.

$vCenterConnection = Connect-VIServer vc1.example.com `

-User 'My User' `

-Password 'My Password'

$certModeSetting = Get-AdvancedSetting "vpxd.certmgmt.mode" -Entity $vCenterConnection

Set-AdvancedSetting $certModeSetting -Value "custom"

После этого нужно сгенерировать CSR-запрос для сервера ESXi. Шаг похож на оный для vCenter Server, только нужно будет указать параметр CommonName. Это должно быть FQDN-имя хоста или его IP-адрес. Убедитесь, что CommonName совпадает с идентификатором, по которому вы добавляли этот хост в vCenter.

$esxRequest = New-VIMachineCertificateSigningRequest `

-VMHost $vmhost `

-Country "US" `

-Locality "San Francisco" `

-Organization "My Company" `

-OrganizationUnit "PowerCLI" `

-StateOrProvince "California" `

-CommonName <ESXi host's FQDN> or <ESXi host's IP address>


$esxRequest.CertificateRequestPEM | Out-File "C:\Users\jdoe\Downloads\esx.csr.pem" -Force

Теперь, когда мы получим сертификат от центра сертификации, нужно выполнить 3 операции:

1. Выводим хост в режим обслуживания (maintenance mode) и удаляем его из vCenter:

$vmhost = Get-VMHost 'MyESXiHost' `

Set-VMHost -VMHost $vmhost -State Maintenance

Remove-VMHost $vmhost

2. Соединяемся с хостом ESXi напрямую, устанавливаем там сертификат и перезагружаем хост:

$esxConnection = Connect-VIServer $vmhost.Name `

-User 'My User' `

-Password 'My Password' `

-Force


$esxCertificatePem = Get-Content "C:\Users\jdoe\downloads\myesxcert.pem" -Raw

$targetEsxHost = Get-VMHost $vmhost.Name

Set-VIMachineCertificate -PemCertificate $esxCertificatePem -VMHost $targetEsxHost | Out-Null



Restart-VMHost $targetEsxHost



Disconnect-VIServer $esxConnection

Так же, как и для vCenter, перед установкой сертификата машины нужно убедиться, что корневой сертификат нашего центра сертификации добавлен в доверенное хранилище сертификатов на хосте ESXi и других серверах, с которыми он взаимодействует, то есть остальные хосты ESXi и vCenter.

Снова добавляем наш хост ESXi в vCenter:

$vCenterConnection = Connect-VIServer vc1.example.com `

-User 'My User' `

-Password 'My Password'


$vmhost = Add-VMHost -Name <ESXi host's FQDN> or <ESXi host's IP address> `

-Location (Get-Datacenter "My Datacenter")`

-User "My User" `

-Password "My Password"


$vmhost = Set-VMHost -VMHost $vmhost -State Connected

Ну и остальные идеи вы можете почерпнуть в документе PowerCLI User’s Guide.

Компания VMware объявила о первом релизе PowerCLI в этом году - на днях стала доступна для загрузки версия PowerCLI 12.5. Напомним, что о прошлой версии этого фреймворка для управления виртуальной инфраструктурой с помощью сценариев мы писали вот тут.

Давайте посмотрим, что там появилось нового:

1. Функции vCenter Server Appliance Service Management

В апдейте PowerCLI появилось 4 новых командлета:

• Get-VIApplianceService – получает список сервисов vCenter Server Appliance (vCSA)
• Start-VIApplianceService – запускает один из сервисов
• Stop-VIApplianceService – останавливает
• Restart-VIApplianceService – перезапускает
  

2. Поддержка VMware Cloud on AWS Outpost

Теперь PowerCLI поддерживает обращение к онпремизной инфраструктуре AWS, которая называется Outpost (стала доступной в конце прошлого года). Для этого есть командлет Get-VmcOutpost, который позволяет получить список доступных аутпостов для организации в VMC. Также при создании SDDC с помощью командлета New-VmcSddc есть параметр -Outpost, который позволяет создать объект в рамках аутпоста.

3. Поддержка Hot add / Remove для процессоров и памяти

Теперь есть новые параметры, в командлетах создания и настройки ВМ (Set-VM и New-VM), которые позволяют включить функции горячего добавления памяти и процессоров, а также удаления процессоров. Вот эти параметры:

• -CpuHotAddEnabled (включить CPU Hot Add)
• -CpuHotRemoveEnabled (включить CPU Hot Remove)
• -MemoryHotAddEnabled (включить Memory Hot Add)

4. Включение шифрованной миграции vMotion

Теперь для командлетов создания и настройки ВМ (Set-VM и New-VM) есть параметр -MigrationEncryption, который позволяет включить шифрованную миграцию.

5. Обновления для Horizon 8.4

Модуль Horizon был обновлен и теперь включает в себя байндинги для Horizon 8.4 API.

Больше информации о новом релизе вы можете узнать вот тут. Скачать VMware PowerCLI 12.5 можно по этой ссылке.

Как знают многие администраторы VMware vSphere, у компании есть очень полезный документ "Security Configuration Guide", который представляет собой основное руководство по обеспечению безопасности виртуальной среды. Последняя версия этого документа содержит 87 настроек (мы писали об этом тут), так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин и их гостевых операционных систем.

Документ передает концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований именно в вашей инфраструктуре.

Надо понимать, что конфигурация виртуальной среды в целях обеспечения повышенной (относительно дефолтной) безопасности - это всегда компромисс между защищенностью и удобством использования (как и для любой другой ИТ-системы). Из коробки сама платформа, сервер vCenter и виртуальные машины настроены таким образом, чтобы обеспечить максимальное удобство использования при должном уровне безопасности.

Помните, что изменение настроек безопасности - очень опасная штука, которая требует обязательного документирования и оповещения администраторов об этом. Ведь из-за этого они могут получить проблемы с работой отдельных компонентов, но так и не понять их источника, что будет похуже чисто гипотетической маловероятной атаки, связанной с измененной настройкой.

Сегодня мы посмотрим на 15 действительно полезных рекомендаций и настроек, применение которых не сильно снизит удобство использования, но при этом даст чуть более высокий уровень безопасности, что может оказаться вам в каком-то случае полезным.

Структура списка конфигураций и рекомендаций

Давайте сначала взглянем на колонки Excel-таблицы, которая, по-сути, и является списком настроек и рекомендаций, которые вы можете применить в своей виртуальной инфраструктуре:

• Guideline ID - идентификационное имя рекомендации.
• Description - лаконичная формулировка сути этой рекомендации.
• Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются удобства использования инструментов управления в связи с изменением настройки.
• Configuration Parameter - это название расширенной настройки соответствующего компонента, которую вы можете изменить. Понятно дело, что эта колонка заполнена не всегда, так как есть рекомендации, которые регулируются не конкретными настройками, а, например, топологией или подходом к организации среды.
• Desired value - рекомендуемое значение, часто оно является значением по умолчанию, если это не site specific.
• Default value - то значение, которое установлено по умолчанию.
• Is Desired Value the Default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
• Action Needed - это тип действия, который необходимо предпринять - изменить настройку, проверить конфигурацию или топологию, добавить или удалить что-то и т.п.
• Setting Location in vSphere Client - очень полезная колонка, позволяющая вам найти нужную настройку в клиенте vSphere.
• Negative Functional Impact in Change From Default? - это как раз информация о влиянии на функционал в случае изменения настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено необоснованно.

Само руководство разбито на 4 категории, которые понятны всем администраторам:

• Хосты ESXi
• Сервер vCenter
• Виртуальные машины
• Гостевые ОС виртуальных машин

Также в документе есть и вкладка "Deprecated" - там находятся те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

Итак, давайте посмотрим на 15 самых интересных и, главное, полезных настроек, которые вы можете изменить, а также рекомендаций, которые вы можете выполнять, чтобы повысить безопасность виртуальной среды в своей инфраструктуре.

Хосты ESXi

• Configure remote logging - это действительно правильная рекомендация. Хосты ESXi должны отправлять свои логи на удаленный сервер Syslog. Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware vRealize Log Insight. Ведь если злоумышленник проникнет на сервер ESXi, то после своей активности он эти логи удалит, и расследовать будет нечего. С централизованного внешнего сервера удалить эти данные сложнее. На работу виртуальной среды эта конфигурация не влияет.
• Ensure ESXi management interfaces are isolated on their own network segment - это очевидная, но не всегда выполняемая администраторами конфигурация. Конечно же, вся управляющая инфраструктура виртуальной среды должна находиться в выделенном сегменте сети в своих VLAN, куда имеют доступ только администраторы. То же самое касается и сети vMotion, и сети vSAN.
• esxi-7.shell-interactive-timeout и esxi-7.shell-timeout (Set a timeout to automatically terminate idle ESXi Shell and SSH sessions) - по умолчанию сессии командной оболочки и SSH-сессии висят постоянно, что, конечно же, представляет потенциальную угрозу. Лучше ограничить таймаут 600 секундами, чтобы никто эти сессии не смог подхватить.
• Only run binaries delivered via VIB - эта настройка позволяет устанавливать бинарные компоненты только через VIB-пакеты, которые соответствуют установленному Acceptance Level. Если вы не пользуетесь посторонними библиотеками кустарного производства, то лучше эту настройку включить. Когда вам понадобится установить такой бинарник - просто включите эту настройку снова. Но это изменение лучше задокументировать.
• Enable bidirectional/mutual CHAP authentication for iSCSI traffic - настраивать CHAP-аутентификацию нужно обязательно, чтобы предотвратить атаки, связанные с перехватом трафика к хранилищам. Настраивать это недолго, но зато будет больше уверенности в сохранности данных.

Сервер vCenter

• Ensure vCenter Server management interfaces are isolated on their own network segment or as part of an isolated ESXi management network - это та же самая рекомендация по изоляции управляющей сети от сети виртуальных машин, что и для серверов ESXi. Убедитесь, что они надежно разделены с помощью VLAN и других техник.
• Ensure that port mirroring is being used legitimately - эта настройка отключена по умолчанию, но зеркалирование трафика на портах vSphere Distributed Switch надо периодически проверять (vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> Port Mirroring). Такой способ атаки - один из самых простых в реализации, если у злоумышленника есть доступ к настройкам VDS (обычно в них никто не заглядывает после первичной настройки). То же самое касается и отправки трафика NetFlow, управление которым производится в разделе vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> NetFlow.
• Limit access to vCenter Server by restricting DCLI / SSH - это разумная рекомендация, чтобы злоумышленник не смог залогиниться в консоль виртуального модуля напрямую или по SSH. Уменьшив поверхность атаки, вы сделаете среду более защищенной. Только не забудьте задокументировать это изменение.
• Configure File-Based Backup and Recovery - не ленитесь настраивать и обслуживать бэкап конфигурации вашего управляющего сервера. Однажды это может вам пригодиться как в контексте безопасности, так и в контексте быстрого восстановления системы управления в виртуальной инфраструктуре в случае сбоя.
• Configure remote logging - здесь те же рекомендации, что и для ESXi. Не ленитесь настраивать сервер удаленного сбора логов.

Виртуальные машины

• Limit the number of console connections - очень часто к консоли виртуальной машины не нужно больше одного подключения ее администратора. В этом случае дефолтное количество 40 одновременных подключений лучше уменьшить до 1. Делается это в разделе VM -> Edit Settings -> VM Options -> VMware Remote Console Options.
• Encrypt VMs during vMotion - это полезная настройка. По умолчанию, трафик vMotion шифруется, только если есть такая возможность (Opportunistic). Если у вас хватает вычислительных ресурсов и быстрая сеть, то можно установить это значение в "Required". Это обеспечит защиту от перехвата трафика vMotion, в котором есть данные гостевой ОС виртуальной машины.
• Lock the VM guest session when the remote console is disconnected - лучше включить эту настройку и лочить сессию при отключении удаленной консоли, чтобы брошенная администратором сессия в гостевой ОС виртуальной машины не была подхвачена злоумышленником. На удобство работы это не сильно влияет. Изменить эту настройку можно в VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

Гостевая ОС

• Ensure that VMware Tools are updated - это просто еще одно напоминание, что нужно постоянно следить за тем, что пакет VMware Tools обновлен до последней версии (и желательно поддерживать единый уровень версий для всех машин). В нем содержится много компонентов (кстати, не устанавливайте ненужные), поэтому уязвимость в одном из них может скомпрометировать множество виртуальных машин. То же самое относится и к версии Virtual Hardware - следите за этим.
• Disable Appinfo information gathering - об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы и их параметрах. Механизм Appinfo используется различными решениями, такими как vRealize Operations Manager, для мониторинга на уровне гостевой ОС. Если же вы не используете эти решения в своей виртуальной среде, то данный механизм лучше просто отключить через VMware Tools. Учитывая какое количество багов, касающихся безопасности, в последнее время находится в различных компонентах инфраструктурного ПО, лучше отключить функции Appinfo, которые включены по умолчанию для всех гостевых ОС после установки VMware Tools.

Конечно же, в документе vSphere 7 Security Configuration Guide есть много и других настроек и конфигураций, изменение которых помогут вам повысить уровень безопасности. Иногда это связано с требованиями регулирующих органов или спецификой внутренних политик организации. Поэтому обратите особенное внимание на те конфигурации, которые помечены как Site Specific, а также те, где рекомендуемые значения отличаются от дефолтных. И обязательно документируйте сделанные изменения, а также проводите регулярный аудит наиболее важных настроек.

Компания VMware выпустила обновление главного фреймворка для управления виртуальной инфраструктурой с помощью командных сценариев - PowerCLI 12.4. Напомним, что в прошлый раз об обновлении этой платформы мы писали вот тут. В обновленной версии PowerCLI появилось несколько новых возможностей:

1. Новый API интерфейс - RestAPI

Раньше PowerCLI имел 2 основных пути коммуникации с vSphere API:

• Get-View (SOAP API bindings)
• Get-CISService (JSON-RPC)

Теперь новые PowerCLI API байндинги позволяют работать vSphere REST API и предоставляют практически нативный интерфейс PowerShell.

Модуль, реализующий эти функции, называется vSphere Automation API SDK. Чтобы начать использовать новые возможности через автоматизацию REST API, нужно скачать новую версию PowerCLI - пакет будет называться "VMware.Sdk.vSphere". Он содержит в себе субмодули для взаимодействия со всеми REST API, которые есть в VMware vSphere.

В REST API есть методы для исполнения API и работы со структурами данных, которые используются как входные параметры для API. Новые API байндинги предоставляют низкоуровневые PowerShell функции для работы со всеми этими методами и структурами.

Функция Invoke используется для исполнения методов REST, таких как GET/PUT/POST и DELETE:

Функция Initialize используется для создания структуры данных, которая будет передана к REST API. Например, так выглядит создание структуры "локальный аккаунт":

$LocalAccountsConfig = Initialize-LocalAccountsConfig -Password 'Tes$TPa$$w0Rd' -Roles 'superAdmin' #Create Account Config

$LocalAccountsCreateRequestBody = Initialize-LocalAccountsCreateRequestBody -Username 'dimilov' -Config $LocalAccountsConfig #Create Account Request Body

Invoke-CreateLocalAccounts -LocalAccountsCreateRequestBody $LocalAccountsCreateRequestBody #Create Local Account

Раздел документации vSphere API Documentation был существенно обновлен - туда были добавлены примеры, показывающие вызов REST API через PowerCLI. Например, вот раздел Create Local Accounts.

2. Новый vSphere Management Module

Для управления платформой vSphere теперь появился новый модуль. Это модуль на базе PowerShell, для построения которого используется архитектура модулей vSphere Automation API SDK, о которой рассказано выше. На данный момент в модуле 6 командлетов, позволяющих управлять сертификатами (по ссылкам вы можете почитать о них):

• Add-VITrustedCertificate
• Get-VIMachineCertificate
• Get-VITrustedCertificate
• New-VIMachineCertificateSigningRequest
• Remove-VITrustedCertificate
• Set-VIMachineCertificate

3. Прочие улучшения

Здесь были улучшены вот какие мелочи:

• Поддержка увеличенных параметров VMC SDDC
• Командлет Copy-DatastoreItem теперь поддерживает upload/download файлов VMDK с хранилищ vSAN
• API байндинги для VMware Horizon были обновлены, чтобы поддерживать все новые API решения Horizon 8.3 (он же 2106)

4. Новый логотип PowerCLI

Теперь он выглядит вот так:

Файлы ресурсов логотипа можно скачать тут.

Загрузить фреймворк VMware PowerCLI 12.4 можно по этой ссылке.

Недавно мы писали о новой версии решения для виртуализации и доставки настольных ПК и приложений VMware Horizon версии 2106. Помимо новых фич, в обновленной платформе появилось много приятных небольших нововведений, одно из них - это возможность вывести список всех событий VMware Horizon прямо в интерфейсе клиента:

Такого рода вещи стали возможны благодаря интерфейсам Audit Events API. Теперь для получения событий пользователям не нужно идти в базу данных с помощью SQL-запросов, а можно просто получать события через API.

Вильям Лам с помощью PowerCLI-сценария обработал файл с определениями событий C:\Program Files\VMware\VMware View\Server\LDAP\ldif\VDIEventStrings_en.ldf на сервере Connection Server и выяснил, что всего в Horizon есть на данный момент 858 типов событий. Эти события он вынес в отдельную табличку:

Также хотим напомнить вам об утилите VMware Horizon Event Notifier, которая соединяется с одной или несколькими базами данных Horizon View Event Database, вытаскивает оттуда выбранные администратором события (ошибки, предупреждения, инфо) и шлет письма на указанный email-адрес. При этом поддерживается возможность работы с несколькими БД, что позволяет собирать алерты с разных инсталляций VMware View (они же View Pods).

Дункан Эппинг обратил внимание на довольно частую проблему у пользователей VMware vSphere 7, которые делают апгрейд с Update 1 на Update 2. Если вы используете подключение к хранилищам по iSCSI и рандомные имена IQN для инициаторов, то после апгрейда хранилища могут перестать быть доступными, если вы используете контроль доступа на базе IQN.

Проблема проявляется, только если вы создавали подключения по iSCSI именно в vSphere 7 Update 1 на свежей установке. Причина проста - изменился стандарт случайного именования IQN для iSCSI-инициаторов. Если для Update 1 он выглядит так:

iqn.1998-01.com.vmware:labesx06-4ff17c83

То для Update 2 уже так:

iqn.1998-01.com.vmware:labesx07:38717532:64

Соответственно, после апгрейда имя инициатора у вас изменится. Чтобы сделать хранилища iSCSI вновь доступными, надо пойти на дисковый массив или виртуальный модуль (Virtual Appliance) и вбить туда новое имя инициатора. Либо вы можете сделать имя инициатора вручную и вбить его также и на массиве для нужных LUN.

Кстати, при апгрейде с версии vSphere 6.7 или vSphere 7 сразу на Update 2 проблема не возникает, так как настройки iSCSI корректно переезжают сразу в configstore.

Чтобы изменить имя iSCSI-адаптера, можно использовать вот эту команду, чтобы это имя получить:

$ esxcli iscsi adapter get -A vmhba67

Вывод будет, например, таким:

vmhba67
Name: iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

И потом вот эту команду, чтобы задать новое имя:

$ esxcli iscsi adapter set -A vmhba67 -n iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

Также можно это сделать и с помощью PowerCLI-сценария (подробнее тут):

Get-VMHost |
ForEach-Object -Process {
    $HostHBA = $_ | Get-VMHostHba -Type iScsi | Select-Object Name,IScsiName
    $esxcli = get-esxcli -v2 -vmhost $_
    $CLIARG =  @{
        adapter = $HostHBA.Name
        name = $HostHBA.IScsiName
        skipifsessionactive = $false
        }
    $esxcli.iscsi.adapter.set.Invoke($CLIARG)
write-host "Setting host " $H  "adapter"  $HostHBA.Name "with IQN" $HostHBA.IScsiName
    }

Если у вас большая Enterprise-инсталляция VMware vSphere, и вам хочется оповещать пользователей о каких-либо важных статусах, изменениях или новостях, то вы можете использовать механизм Message of the Day (MotD) - сообщение, которое появляется в верхней части экрана vSphere Client. Например, пользователям можно сообщить, что они работают в Sandbox-окружении:

Вильям Лам рассказал о том, как правильно можно работать с этим с точки зрения автоматизации. В интерфейсе это сообщение можно настроить в разделе Configure->Settings->Message of Day:

Как видно из картинки выше, в этом сообщении поддерживаются специальные символы и эмоджи. Вот так это будет выглядеть для пользователей:

Ну и главное - как это автоматизировать, если у вас несколько окружений vCenter?

Вот такой командой можно получить сообщение дня через PowerCLI:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vpxd.motd | select Value

К сожалению, с помощью Set-AdvancedSetting нельзя установить это сообщение, так как для обертки API это свойство находится в статусе Read Only. Поэтому нужно использовать API напрямую.

Вот так можно посмотреть текущий MotD:

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager

$sm.Message

А вот так - обновить его:

$motd = "This is William Lam's environment, it is NOT supported. Use at your own risk"

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager

$sm.UpdateServiceMessage($motd)

Некоторые администраторы VMware vSphere хотели бы закрыть доступ для некоторых пользователей к интерфейсу vSphere Client или ограничить его определенными адресами, оставив доступ через API. Например, это нужно тогда, когда пользователи vSphere не соблюдают установленные процедуры и регламенты при работе в интерфейсе клиента (например, не фиксируют внесенные в конфигурации виртуальных машин изменения).

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

Да, и надо не забыть, что для того, чтобы изменения веб-сервера вступили в силу, надо его перезапустить командой:

service-control --restart vsphere-ui

На сайте проекта VMware Labs появилась новая версия утилиты Virtual Machine Compute Optimizer 3.0, о которой в последний раз мы писали летом 2019 года. С тех пор вышло несколько обновлений этого средства. Напомним, что VMCO - это PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.

В третьей версии сценария появился рабочий процесс установки/апгрейда всех необходимых модулей - VMCO и PowerCLI. Теперь это единый сценарий, в котором есть мастер, проходящий по всем шагам установки модулей, соединения с vCenter и экспорта результатов.

Также в последних версиях была добавлена опция -simple, которая позволяет отобразить только информацию о виртуальных машинах (без серверов vCenter, кластеров и хостов ESXi), обновлена документация и исправлено много ошибок.

Скачивайте Virtual Machine Compute Optimizer 3.0 и выясняйте, правильно ли у вас настроены vCPU и Memory для виртуальных машин. Надо понимать, что VMCO анализирует вашу инфраструктуру только на базе рекомендаций для оптимальной конфигурации виртуальных машин без учета реальной нагрузки, которая исполняется внутри.

На сайте проекта VMware Labs обновился основной клиент VMware vSphere на базе технологии HTML5 (он же vSphere Client в составе платформы VMware). Напомним, что старый клиент Web Client на базе Adobe Flex ушел в прошлое, и VMware предлагает использовать только новый клиент для управления виртуальной инфраструктурой.

Кстати, VMware vSphere HTML5 Web Client версии 5.0 (build 15670023) - это первое обновление клиента за довольно долгое время. Давайте посмотрим, что там появилось нового:

• Обновлена документация (в том числе инструкции, где находятся файлы и сервисы клиента)
• Добавлен новый язык для функции Code Capture - теперь записанные во время сессии действия могут транслироваться в код на языке Go.
• PowerActions - это новый механизм интеграции PowerCLI и vSphere Client. Теперь в клиенте есть функциональность по запуску отдельных команд и сценариев PowerCLI, а также функции их хранения в библиотеке скриптов. Исполнение кастомных действий скриптов можно привязать к объектам из inventory в клиенте.
• Функцию PowerActions надо включать отдельно при развертывании клиента (см. документ PowerActions_documentation_Fling50.pdf).

Базовая операционная система виртуального модуля vSphere Client была заменена на Photon OS, поэтому апгрейд с прошлой версии не поддерживается - придется развертывать все по-новой.

Загрузить новую версию клиента VMware vSphere HTML5 Web Client 5.0 можно по этой ссылке. Инструкции по установке и использованию доступны тут. Также много всего интересного есть в комбо-боксе выбора компонентов загрузки:

У компании VMware есть полезная бесплатная электронная книга PowerCLI Cookbook for VMware vSAN, посвященная управлению инфраструктурой отказоустойчивых хранилищ с помощью сценариев, которая будет полезна всем администраторам хранилищ виртуальных сред vSphere / vSAN.

В книге на 127 страницах подробно рассказывается о командлетах для управления всеми аспектами хранилищ с помощью PowerCLI. В документе 3 основных блока:

• Configuration Recipes - разбор примеров использования сценариев для настройки самого окружения vSAN, а именно:
  • Настройка vSAN в новом или существующем кластере
  • Добавление хостов
  • Настройка сетевого окружения
  • Выделение дисков под хранилища
  • Настройка HA и DRS
  • Настройка дедупликации и компрессии
  • Настройка шифрования
  • Конфигурация vSAN Performance Service
• Operational Recipes - это практические примеры сценариев для ежедневного использования и подробный разбор их параметров, а также описание процедур, которые нужно регулярно выполнять в кластере.
• Reporting Recipes - это набор рецептов для вывода информации о конфигурациях, метриках и состояниях, а также представления данных в удобном виде.

Скачивайте PowerCLI Cookbook for VMware vSAN - штука полезная.

Команда PowerCLI компании VMware на днях выпустила обновление средства vSphere Desired State Configuration (DSC) версии 2.2. Механизм DSC есть в экосистеме Windows, начиная еще с Windows Server 2012 R2. С помощью него можно мониторить и управлять конфигурациями систем посредством специальных конфигурационных файлов на базе PowerShell, которые имплементируются через движок Local Configuration Manager (LCM), который должен быть на каждом хосте.

У VMware этот механизм работает несколько иначе, в качестве LCM используется прокси-хост, поскольку LCM не запустить ни на vCenter Server Appliance, ни на ESXi:

Так работал механизм до текущего момента, когда пользователям приходилось разворачивать отдельную Windows-машину под LCM. Но теперь появился модуль VMware.PSDesiredStateConfiguration, который предоставляет пользователям набор командлетов, чтобы скомпилировать и исполнить конфигурацию DCS без использования DSC Local Configuration Manager. Это позволяет использовать как Windows, так и Linux-машину в качестве прокси.

При этом пользователям по-прежнему предоставляется возможность использовать как vSphereDSC с движком PowerShell LCM, так и модуль VMware.PSDesiredStateConfiguration.

Давайте посмотрим, что нового появилось в DCS версии 2.2:

1. Новые ресурсы PowerCLI модуля

Вот они:

1. DatastoreCluster - создание, изменение, апдейт или удаление Datastore cluster
2. DatastoreClusterAddDatastore - добавление датастора к Datastore cluster
3. DRSRule - создание, изменение, апдейт или удаление правил DRS
4. VMHostVdsNic - изменение, апдейт или удаление "VMKernel nic" на vSphere Distributed switch
5. VMHostStorage - включение или отключение программного iSCSI-адаптера 
6. VMHostIScsiHbaVMKernelNic - используется для bind/unbind адаптеров VMKernel Network Adapters к указанному iSCSI Host Bus Adapter

2. Исправления ошибок

Поправлены ошибки в следующих командлетах:

• VMHostVDSwitchMigration 
• VMHostVssTeaming
• NfsDatastore

3. Операция Install/Update для модуля VMware vSphereDSC

Установка модуля теперь делается так:

Install-Module -Name VMware.vSphereDSC

Обновление вот так:

Update-Module -Name VMware.vSphereDSC

4. Новый модуль VMware.PSDesiredStateConfiguration

Как было сказано выше, теперь вы можете использовать Windows или Linux-машину без LCM для использования механизма DCS. Установить модуль можно следующей командой:

Install-Module -Name VMware.PSDesiredStateConfiguration

Новый командлет New-VmwDscConfiguration создает объект VmwDscConfiguration, который содержит информацию о конфигурации. Эту конфигурацию можно задать в ps1-файле и передать ее данному командлету. Например:

$config = New-VmwDscConfiguration -Path ./Site-A.ps1

Командлет Start-VmwDscConfiguration запускает исполнение конфигурации:

Start-VmwDscConfiguration -Configuration $config

Есть командлет Test-VmwDscConfiguration для проверки соответствия текущей конфигурации описанной:

Test-VmwDscConfiguration -Configuration $config

Можно также использовать параметр -Detailed для вывода полной информации по соответствию:

Test-VmwDscConfiguration -Configuration $config -Detailed

5. Новая динамическая конструкция vSphere Node

С помощью vSphere Node можно указать объект VINode (сервер vCenter или хост ESXi) и применить соответствующую конфигурацию к нужному узлу vSphere. Это дает следующие возможности:

• Персистентные сессии

Раньше для каждого подключения каждый ресурс требовал параметров учетной записи для установки сессии VISession. Теперь же если вы используете Vmware.PSDesiredStateConfiguration то можно создать персистентную VISession, которую можно использовать для всех ресурсов DCS.

• Не нужны файлы MOF

Поскольку LCM теперь не используется, то и для командлета New-VmwDSCconfiguration они не требуются. Конфигурация может храниться в переменной, либо в ps1-файле.

Скачать VMware vSphere DSC 2.2 можно по этой ссылке.

На сайте проекта VMware Labs появилась очередная полезная штука - Community Networking Driver for ESXi. Этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe.

Драйверы можно установить для VMware ESXi 7.0 или более поздних версий, а список поддерживаемых устройство выглядит так:

Установить драйвер можно с помощью команды:

esxcli software vib install -d /path/to/the offline bundle zip

После этого нужно обязательно перезагрузить ваш ESXi, до перезагрузки сетевой адаптер работать не будет.

Также если вы хотите использовать драйвер для Intel NUC 11, вам нужно будет встроить его в образ ESXi (Image Profile). Для этого можно использовать графический интерфейс Image Builder в vSphere Client, либо Image Builder CLI на базе PowerCLI.

Скачать пакет драйверов Community Networking Driver for ESXi можно по этой ссылке.

На днях компания VMware обновила свой главный документ, касающийся обеспечению безопасности виртуальных сред и самой платформы виртуализации - VMware vSphere 7 Security Configuration Guide. Напомним, что о его прошлой версии осенью прошлого года мы писали вот тут.

Давайте посмотрим, что появилось нового в обновленном SCG для vSphere 7, который традиционно состоит из PDF-файла описания и XLS-файла настроек, рекомендаций и пояснений:

• Исправлены ошибки в рекомендациях PowerCLI для аудита виртуальных машин.
• Добавлена вкладка "Deprecated" - там теперь будут те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

• Настройка svga.vgaOnly перемещена в Deprecated. Она ограничивает ВМ на использование только VGA-разрешений, а многие современные ОС этого очень не любят (могут даже отключить отображение картинки в этом случае).
• Добавлены и обновлены рекомендации по отключению сервисных служб SLP и CIM на сервере ESXi. Эти протоколы часто не используются (их не используют и продукты VMware), поэтому лучше их отключить.
• Добавлены рекомендации по изоляции сети. Раньше как-то само собой подразумевалось, что нужно разделять сети управления, vMotion и vSAN, теперь же это формализовано в документе. Там же рекомендовано и физическое разделение сетей.
• Добавлена рекомендация по использованию только тех продуктов, старые версии которых еще официально поддерживаются со стороны VMware (например, вы можете выполнить все рекомендации и накатить все обновления, но использовать старый ESXi 5, что по понятным причинам небезопасно).
• Добавлено руководство по использованию модулей Trusted Platform Modules 2.0 (TPM).
• Снова возвращена рекомендация vm-7.pci-passthrough, касающаяся прямого доступа виртуальных машин к оборудованию, в частности шине PCIe.
• Добавлено руководство по отключению интерфейсов DCLI, если вы не используете его на vCenter Server. Также вам не нужно держать SSH постоянно открытым, так как в vSphere широкий и защищенный API, который вы можете использовать в разных фреймворках и утилитах.

Скачать VMware vSphere 7 Security Configuration Guide (как и руководства для других версий vSphere) можно по этой ссылке. Подробнее о документе также можно почитать тут.

Наш постоянный читатель Сергей обратил внимание на то, что на днях компания VMware выпустила обновление своего главного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 12.2. Напомним, что о прошлой версии PowerCLI 12.1 осенью прошлого года мы писали вот тут.

Давайте посмотрим, что нового появилось в обновленном PowerCLI 12.2:

1. Поддержка VMware Horizon

Модуль PowerCLI для управления инфраструктурой Horizon теперь поддерживается для macOS и Linux OS.

2. Инфраструктура VMware Cloud

Появилась поддержка одного из самых популярных сервисов для обеспечения катастрофоустойчивости датацентров - DRaaS. Новые командлеты позволяют включать/отключать DRaaS в виртуальном датацентре VMC SDDC, а также добавлять и удалять инстансы SRM (Site Recovery Manager).

Вот так выглядит включение DRaaS:

Управление инстансами SRM происходит с помощью командлетов:

• Get-VmcSddcSiteRecoveryInstance
• New-VmcSddcSiteRecoveryInstance
• Remove-VmcSddcSiteRecoveryInstance

3. Поддержка VMware vSphere

• Расширенная поддержка vSphere Lifecycle Manager (vLCM)
  • Новые командлеты для экспорта и импорта состояния кластера
  • Новые командлеты для получения рекомендаций vLCM (Get-LcmClusterDesiredStateRecommendation)
  • Новые командлеты для получения аппаратной совместимости компонентов со стороны vLCM
  • Улучшенный командлет Set-Cluster для добавления кастомного репозитория ROBO-окружений
• Расширенная поддержка параметров OVF для объектов Content Library
• Добавлена поддержка шаблонов ВМ в Content Library
• Операция Foreach-object -Parallel теперь поддерживается

Вот так выглядит экспорт состояния кластера:

А вот так импорт:

4. Управление рабочими нагрузками

• Новые командлеты для управления лимитами пространств имен:
• Get-WMNamespaceLimits
• Set-WMNamespaceLimits

5. Поддержка NSX-T

• Теперь поддерживаются API компонента NSX-T global manager

Больше подробностей и примеров использования новых фич вы можете найти вот в этой статье. Скачать VMware PowerCLI 12.2 можно по этой ссылке.

Администраторы VMware vSphere в больших инфраструктурах иногда используют кластеры Windows Server Failover Clusters (WSFC) на базе RDM-дисков, которые доступны для хостов VMware ESXi. Ранее они назывались Microsoft Cluster Service (MSCS). При использовании таких кластеров время загрузки хоста ESXi может вырасти аж до целого часа, если не поставить этим LUN статус Perennially reserved.

Суть проблемы в том, что WSFC ставит SCSI-3 reservations для своих LUN, используемых активным узлом, и если ESXi видит эти тома (то есть они не отмаскированы для него), то он безуспешно пытается получить к ним доступ. Для этого он делает несколько попыток при загрузке, пока не решает перейти к следующим томам. Статус этих операций вы можете увидеть, если нажмете Alt+F12 при загрузке хоста:

Xavier Avrillier написал статью о том, как с помощью esxicli/PowerCLI пометить такие тома как Perennially reserved, чтобы ESXi пропускал их при сканировании (об этом также рассказано в KB 1016106).

Сначала вам надо узнать LUN canonical name устройства. Делается это следующей командой PowerCLI:

PS> Get-VM MSCS-Node-1 | Get-HardDisk -DiskType RawPhysical | select scsicanonicalname
ScsiCanonicalName

  —————–

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbc

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbb

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacba

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbd

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacb9

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacb8

Далее для нужного id-устройства устанавливается статус Perennially reserved через esxcli:

esxcli storage core device setconfig -d naa.id –perennially-reserved=true

Но удобнее это же сделать и через PowerCLI (ищем диски у машин по шаблону MSCS-Node-*):

PS> Set-PerenniallyReserved -PerenniallyReserved $True -VMHost (Get-VMHost) -HardDisk (Get-VM MSCS-Node-* | Get-HardDisk -DiskType RawPhysical)

Ну а для тех, кто хочет использовать vSphere Client, недавно появилась опция "Mark as Perennially Reserved" в разделе Storage Devices клиента:

Главное - не ошибитесь в выборе LUN, если вы отметите не то - это может привести к весьма печальным последствиям.

Источник.

Многие администраторы в крупных инфраструктурах сталкиваются с проблемами назначения и обновления лицензий компонентов VMware vSphere - серверов ESXi и vCenter. Это можно сделать в графическом интерфейсе vSphere Client, но когда у вас много хостов, это становится муторным делом, во время которого легко ошибиться или просто устать:) Давайте посмотрим, как можно просто это делать через PowerCLI...

Иногда администратор VMware vSphere задается вопросом о происхождении виртуальной машины - из какой родительской ВМ/шаблона она была клонирована? Вильям Лам разбирает это в своей статье, приведем вкратце его метод определения происхождения ВМ.

Как вы знаете, бывает три типа клонирования виртуальных машин в VMware vSphere:

• Full Clone - это полный клон, то есть независимая копия виртуальной машины, у которой нет ничего связанного с родительской ВМ, это просто ее полная копия.
• Linked Clone - это копия виртуальной машины, которая имеет общие диски с родительской, доступные на чтение (это экономит пространство и позволяет просто откатываться к родительскому образу). Уникальные данные эта машина хранит в собственных дельта-дисках.
• Instant Clone - это независимая копия виртуальной машины, которая начинает исполняться с какого-то момента и отделяется от основной машины. Для этого используются техники in-memory cloning и copy-on-write, которые используются также и для связанных клонов.

Чтобы найти источник клонированной машины, нужно проанализировать события vCenter Server Events. Вот какие они бывают касательно клонов:

• VmClonedEvent - появляется, когда происходит создание Full Clone или Linked Clone.
• com.vmware.vc.VmInstantClonedEvent - происходит при созданиии Instant Clone.
• VmDeployedEvent - вызывается, когда виртуальная машина развертывается из шаблона (vSphere Template или Content Library Template).

На базе анализа этих трех событий в истории vCenter Вильям Лам создал PowerCLI-функцию Get-VMCloneInfo, с помощью которой можно узнать родителя для виртуальной машины, если она была клонирована.

Устанавливаем ее простой командой:

Install-Script VMCloneInfo

На входе эта функция принимает имя ВМ, которую мы хотим проанализировать. Такой вывод мы получим, если машина не была клонирована:

> Get-VMCloneInfo -VMName "SourceVM"

Unable to find any cloning information for SourceVM, VM may not have been cloned or vCenter Events have rolled over

Так будет выглядеть вывод по полному клону:

> Get-VMCloneInfo -VMName "Full-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVM 1/3/2021 1:13:00 PM VSPHERE.LOCAL\Administrator

Так мы узнаем, что машина является связанным клоном:

> Get-VMCloneInfo -VMName "Linked-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Linked SourceVM 1/3/2021 1:13:14 PM VSPHERE.LOCAL\Administrator

Так - что Instant-клоном:

> Get-VMCloneInfo -VMName "Instant-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Instant SourceVM2 1/3/2021 1:12:44 PM VSPHERE.LOCAL\Administrator

Вот пример того, что машина была клонирована из шаблона vSphere Template:

> Get-VMCloneInfo -VMName "VMTX-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVMTXTemplate 1/3/2021 2:20:31 PM VSPHERE.LOCAL\Administrator

А вот - что из шаблона Content Library VM Template:

> Get-VMCloneInfo -VMName "VMTemplate-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVMTemplate 1/3/2021 2:23:41 PM VSPHERE.LOCAL\Administrator

Многие администраторы VMware vSAN задаются вопросом - а сколько прослужат диски в кластере хранилищ? Сегодня для vSAN уже имеет смысл использовать только SSD-диски, так как их стоимость уже вполне стала приемлемой для построения All-Flash хранилищ.

Как известно, в кластере vSAN есть 2 типа дисков - Cache (кэширование данных перед записью на постоянное хранение) и Capacity (постоянное хранилище). В первом случае, конечно же, использование ресурса диска идет в разы быстрее, чем для Capacity Tier.

Florian Grehl в своем блоге провел замер использования дисков обоих ярусов в плане записанных гигабайт в сутки в тестовой лаборатории. Вы сами сможете сделать это с помощью его PowerCLI-сценария, а также визуализовав данные в Graphite.

У него получилась вот такая картина:

В день у него получилось:

• 300 ГБ на диски Caching tier
• 20 ГБ на диски Capacity tier

Надо понимать, что объем записанных данных на каждый диск зависит от числа дисков в группе, а также развернутого типа RAID и политики FTT.

Когда вы покупаете SSD-диск, гарантия на него идет как на машину: время (обычно 5 лет), либо пробег (а в случае с диском это "TBW" = Terabytes Written, то есть записанный объем в ТБ) - в зависимости от того, что наступит раньше.

Как правило, для Capacity tier ресурс TBW за 5 лет на практике выработать не получится, а вот для Caching tier неплохо бы этот параметр замерить и сопоставить с характеристиками дисков. Например, 300 ГБ в день дает 535 ТБ за 5 лет.

Ну а вот параметры TBW, например, для устройств Samsung:

Как видно из таблицы, некоторые устройства могут прослужить вам значительно меньше 5 лет, в зависимости от интенсивности использования в вашей инфраструктуре и модели устройства.

Недавно компания VMware полностью переработала портал документации для разработчиков. Там произошел редизайн интерфейса, была улучшена категоризация, а также юзабилити в целом. При этом ранее документация по PowerCLI существовала отдельно от этого портала.

Теперь домашняя страница VMware PowerCLI полностью интегрирована в портал документации, а также получила много новых фич. Давайте на них взглянем:

1. Компоновка домашней страницы

Теперь с нее вы можете перейти на:

• Сообщество разработчиков
• Пример репозитория на GitHub
• Фиче-реквесты
• Блог PowerCLI
• Release notes
• Сhangelog
• Руководство пользователя

То есть это теперь простая и удобная, но функциональная стартовая страница.

2. Организация командлетов по продуктам

Ранее все командлеты были организованы по модулям, что было неудобно для пользователей. Теперь стало намного удобнее, потому что можно проваливаться в каталог командлетов по продуктам:

3. Глобальный поиск

Неважно, какой раздел вы смотрите сейчас, вы всегда сможете воспользоваться функцией глобального поиска:

4. Вкладка структуры данных

Разделы помощи ориентированы на объекты PowerCLI. Теперь на отдельной вкладке Data Structure можно увидеть, как эти объекты обрабатываются со стороны командлетов.

5. Категории

В рамках разделов по продуктам можно искать командлеты по понятным категориям из меню слева:

6. Страница CMDLET Reference

Эта страница позволяет понять как устроен командлет, и как он используется. Работает подсветка кода, и приведены простые примеры использования, которые вы можете скачать и уже самостоятельно изменять для получения наглядного результата. Вот пример такой страницы для командлета Connect-VIServer.

В общем - пользуйтесь.

Большинство администраторов, которым требуется управление виртуальной инфраструктурой VMware vSphere с помощью сценариев используют интерфейс VMware PowerCLI, который является оберткой движка PowerShell. Это требует наличие отдельного хоста, с которого идет исполнение сценариев, а также часто требуются такие сервисы, как vRealize Orchestrator и vRealize Automation.

Поэтому, начиная с VMware vSphere 6.7, появился новый Open Source интерфейс для управления виртуальной средой - Script Runtime Service (SRS). Он представляет собой Kubernetes-приложение для управления инстансами PowerCLI и вызова командлетов через REST API.

Интерфейс SRS позволит интегрировать управление исполнением сценариев PowerCLI в vSphere Client для виртуальных машин и приложений.

SRS создает отдельное пространство имен в кластере Kubernetes, которое позволяет PowerCLI работать как Kubernetes pod. Этот легковесный PowerCLI pod реализуется как образ контейнера, который имеет все модули PowerCLI и требует только необходимые управляющие компоненты, трансформирующие ввод и вывод для сценариев, а также управляющие исполнением запрошенного сценария.

Первоначальная инсталляция SRS запускает задачу Kubernetes, которая регистрирует SRS в сервисах провайдера идентификации vSphere SSO. Единожды аутентифицированные клиенты SRS API автоматически включаются в список доверенных на серверах vCenter.

Надо отметить, что сейчас SRS находится еще в ранней стадии разработки и не работает с vSphere with Tanzu (поэтому не развертывайте его со службами Supervisor Cluster).

Попробовать работу с движком SRS можно двумя путями:

1. Устанавливаете SRS в кластере Kubernetes на любую из машин (инструкции здесь)

2. Устанавливаете SRS на специальным образом подготовленную виртуальную машину на базе Photon OS (инструкции тут).

Начать экспериментировать с SRS API можно, перейдя по ссылке:

https://{SRS-IP}/swagger/index.html

SRS использует механизм vCenter Server SSO для идентификации и аутентификации. У любого пользователя с доступом через SSO есть возможность настроить PowerCLI-соединения к серверам vCenter Servers. Как начать это делать описано вот тут.

SRS работает с vSphere 6.7 и более поздними версиями. Сообщить о проблемах вы можете вот тут, а также присодинившись к VMware Code и каналу в Slack.

В прошлом году мы писали о полезной утилите VMware Configuration Maximums Tool, которая позволяет выводить максимальные конфигурации для различных продуктов VMware. Эта очень полезная штука для администраторов vSphere умеет не только выводить список всех максимумов, но и сравнивать их для разных версий одного продукта.

Для этого нужно выбрать пункт меню "Compare Limits" и указать сравниваемые версии продуктов:

Штука эта очень удобная, но у нее есть большой недостаток - она выводит все конфигурации максимумов (для NSX-T, например, их 274 штуки, поэтому сложно отследить, что именно изменилось).

Поэтому Dale Coghlan написал интересный PowerCLI-модуль VMware.CfgMax, который решает эту проблему - в режиме командной строки можно узнать об изменениях максимумов, а также сделать еще несколько полезных вещей.

После установки модуля можно вывести список доступных продуктов, которые есть на configmax.vmware.com:

Для конкретного продукта можно вывести список его версий/релизов:

Также для конкретной версии можно вывести список категорий максимумов:

С помощью командлета можно вывести все максимумы для конкретного продукта и определенной его версии:

Можно вывести все конфигурации в рамках заданной категории:

Ну и, наконец, с помощью командлета Compare-CfgMaxLimits можно сравнить максимумы конфигураций для разных версий одного продукта:

Как вы видите, тут есть поле CompareStatus, которое и говорит нам, новая ли эта настройка (New), измененная по сравнению с прошлым релизом (Modified), нетронутая (пусто) или удаленная (Deleted) в новой версии.

С помощью параметра New можно, например, вывести все новые настройки:

Параметр Modified выведет только отличающиеся максимумы конфигураций:

Ну а параметр Deleted выведет устаревшие настройки:

Ну и все вместе, без неизмененных значений:

Очень удобная штука, все это также можно экспортировать в формат CSV и сравнивать в Excel. Для этого можно использовать следующую команду:

PS > $product = Get-CfgMaxProduct -Name 'NSX-T Data Center'
PS > $releaseA =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.0.0'
PS > $releaseB =  $product | Get-CfgMaxRelease -Version 'NSX-T Data Center 3.1.0'
PS > Compare-CfgMaxLimits -Product $product -Release $releaseA -CompareRelease $releaseB | Export-Csv -Path compare-status.csv -NoTypeInformation

Скачать данный PowerCLI сценарий с примерами вы можете по этой ссылке.

Недавно компания VMware объявила о доступности для загрузки новой версии фреймворка для управления виртуальной инфраструктурой с помощью сценариев PowerCLI 12.1. Напомним, что о прошлой мажорной версии PowerCLI 12, вышедшей в апреле этого года, мы писали вот тут.

Давайте посмотрим, что нового появилось в PowerCLI 12.1:

• Несколько новых командлетов было добавлено в модуль VMware.VimAutomation.WorkloadManagement
  • Get-WMCluster
  • Set-WMCluster
  • Enable-WMCluster
  • Disable-WMCluster
• Несколько новых командлетов для vSphere Lifecycle Manager (vLCM) было добавлено в модуль VMware.VimAutomation.Core (подробнее тут)
  • Get-LcmImage
  • Test-LcmClusterCompliance
  • Test-LcmClusterHealth

Вот пример работы Get-LcmImage:

• В модуле VMware.VimAutomation.Core было сделано несколько улучшений, включая новые параметры для командлетов New-Cluster и Set-Cluster, а также New-ContentLibraryItem и Set-ContentLibraryItem. Также были несколько обновлены параметры командлетов New-VM/Set-VM, New-Datastore, New-HardDisk и Get-NetworkAdapter/Get-VirtualNetwork
• Несколько новых командлетов было добавлено в модуль VMware.VimAutomation.Vmc:
  • Get-VmcClusterEdrsPolicy
  • Set-VmcClusterEdrsPolicy

• Обновлен модуль VMware.VimAutomation.Vmc:
  • Улучшен командлет New-VmcSddc (добавлены параметры SddcAppliancesSize, StretchedCluster, HostType)
  • Добавлен параметр Cluster в командлеты Add-VmcSddcHost и Remove-VmcSddcHost
  • Свойства VCenterHostName и VCenterCredentials  добавлены объекту SDDC
• В модуле VMware.VimAutomation.Storage появилось несколько новых командлетов для управления безопасной очисткой дисков vSAN, томами Cloud Native Storage и контейнерами VVols:
  • Start-VsanWipeVsanDisk
  • Get-VsanWipeDiskState
  • Stop-VsanWipeVsanDisk
  • Get/New/Set/Remove-CnsVolume
  • New-CnsContainerCluster
  • New-CnsKubernetesEntityReference
  • New-CnsKubernetesEntityMetadata
  • New-CnsVolumeMetadata
  • Add-CnsAttachment
  • Remove-CnsAttachment
  • Get-VvolStorageContainer
• Улучшения модуля VMware.VimAutomation.Storage:
• Командлеты Set-VsanClusterConfiguration и Get-VsanClusterConfiguration теперь поддерживают режимы "vSAN compression only mode" и "vSAN enforce capacity reservation"
• Get-VsanSpaceUsage более гранулярно показывает статистику свободного пространства
• Командлеты Get-VasaStorageArray и Get-VasaProvider теперь могут фильтровать VASA providers по контейнерам VVols
• Моуль VMware.VimAutomation.Security был существенно обновлен:
• Добавлен командлет Get-TrustedClusterAppliedStatus для получения примененного статуса доверенных сервисов в доверенных кластерах
• Добавлен командлет Set-TrustedCluster для ремедиации кластера в состоянии "not healthy"
• Улучшены командлеты New-TrustAuthorityKeyProvider, Set-TrustAuthorityKeyProvider, Add-TrustedClusterAttestationServiceInfo, Add-TrustedClusterKeyProviderServiceInfo, Remove-TrustedClusterKeyProviderServiceInfo, Remove-TrustedClusterAttestationServiceInfo
  
• Добавлен командлет Disconnect-Vcs в модуль VMware.CloudServices для отключения от сервера VMware Cloud Services
• Модуль VMware.Vim теперь содержит API-байндинги для vSphere 7.0 Update 1
• Модуль VMware.VimAutomation.Srm обновлен в целях поддержки VMware Site Recovery Manager 8.3.1
• Модуль VMware.VimAutomation.HorizonView обновлен в целях поддержки VMware Horizon 7.13
• Модуль VMware.VimAutomation.Hcx обновлен в целях возможности настройки VMware Cloud Director как таргета для миграции HCX OS Assisted
• Командлет Wait-HCXJob теперь лучше получает статус Update-HCXSentinel

Скачать VMware PowerCLI 12.1 можно по этой ссылке, там же доступна и документация.

На прошлой неделе компания VMware выпустила новую версию своего основного руководства по обеспечению информационной безопасности виртуальной инфраструктуры VMware vSphere Security Configuration Guide 7 (SCG 7). Теперь документ содержит 78 настроек, так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин.

Что нового появилось в руководстве:

• Совместимость с гайдлайнами по безопасности NIST 800-53, NIST 800-171, CMMC, PCI DSS, ISO 27001, NERC CIP
• Учет аппаратных уязвимостей CPU, таких как Meltdown и Spectre
• Покрытие конфигурациями новых технологий и функциональности платформы vSphere 7

Напомним, что этот документ доносит концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований в вашей инфраструктуре.

В документе, помимо описания рекомендуемой настройки и лога изменений, есть следующие полезные колонки:

• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно. 
• Desired value - рекомендуемое значение, оно же и является значением по умолчанию, если это не site specific.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.

Помимо основного Excel-файла с настройками, в составе скачиваемого архива есть и руководство по применению настроек и работе с ними:

Скачать VMware vSphere Security Configuration Guide 7 одним архивом можно по этой ссылке. Конечно же, документ стоит посмотреть всем специалистам по ИБ, в компетенцию которых входит работа с безопасностью виртуальной инфраструктуры.